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Figure 4 - Dynamic Update Algorithm 
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Figure 1 - Computer Objea 8l Associated Attributes 
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checking thai the new computer module is compadble with ihe old computer 
module; and 



e. making active the new computer module and making inactive the old computer 

module if the new computer module is compatible with the old computer module. 

A method as recited in claim 7, whereby the new computer module is a more current 
version of the old computer module. 

A method as recited in claim 7, further comprising the step of: checking that the request to 
update has valid authorization prior to calling the loader computer module. 

A method as recited in claim 7. whereby the old and new computer modules are NetWare 
loadable modules. 

A method as recited in claim 7, whereby the old and new computer modules provide 
direacry services, 

A method of dynamically updating an old computer module being used on a ser/cr in a 
client/server network with a new computer module, comprising the steps of: 

a. receiving! a request to update an old computer module; 

b. calling aJoader computer module, which routes requests from the old computer 
nrodule, liaving the basic functionality of the old computer module; 

c. loading a new computer module to replace the old computer module; 

d. checking that the new computer module is compatible with the old computer 
module; and 

t: making active the new computer module and making inactive the old computer 
module if the new computer module is compatible with the old computer module. 

A method as recited in claim 12, whereby the new computer module is a more current 
version of the old computer module. 
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14. A method as recited in claim 12. funhcr comprisi;,g the step of: checking that the request 
to update has valid authorization prior to calling the loader computer module. 

15. A method as recited in claim 12. whereby the old and new computer modules are 
5 -NetWwc-ioadable modules. 



16. A method as recited in claim 12. whereby the old and new computer modules provide 
directory services. 
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Tabic 5 • Code Fragments Implementing DSLoader Response to Step 7 



int DSLNegotiateVersions (uint32 dsVersion, uinc32 •dslVersion, 
uint32 * registeredDSVersion) 

( 

•dslVersion = INTEIWAL.VERSION; 
•registeredDSVersion = register«dVersion; 

dsVersion = dsVersion;^ 

return ACCEPTABLE.DS.VERSION (dsVersion ) ? 0: ERR.INVALID.DS.VERSION; 



As indicated by the above n^thod, the computer programs providing services to a 
distributed directory can be dynamically updated without interrupdon of directory services. Thus, 
15 cridcal directory related services can be updated and new service enhancements can be added 
without interrupdon. 

Although one embodiment of the invendon has been illustrated and described, various 
nwdifications and changes may be made by those skilled in the an without departing from the 
spirit and scope of the invendon. 

20 
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Claims 

1. A method, in a computer network, of dynamically updating an old computer module w,th 
a new computer, comprising the steps of: 
5 a. receiving a request to update an old computer module; 

b. calling a loader computer module, which routes requests from the old computer 
module, having the basic functionaiity of the old computer module: 

c. loading a new computer module to replace the old computer module; and 

d. making active the new computer module and making inactive the old computer 
^0 module. 

2. A method as recited in claim 1 . whereby the new computer module is a more current 
version of the old computer module. 



15 3. 



4. 



25 6. 



30 



A method as recited in claim 1. funhcr comprising the step of: checking that the request to 
update has valid authorization prior to calling the loader computer module. 



A method as iwited in claim 1. further comprising the step of: checking that the new 
computer module is compatible with the old computer module prior to unloading the old 
20 computer module. 



A method as recited in claim I. whereby the old and new computer modules arc NetWare 
loadable modules. 



A method as recited in claim 1. whereby the old and new computer modules provide 
dircaory services. 

-A method, in a computer network, of dynamically updating an old computer module with 
a new computer module, comprising the steps of: 

a. receiving a request to update an old computer module: 

b. calling a loader computer module, which routes requests from the old computer 
module, having the basic functionality of the old computer module: 

c. loading a new computer module to replace the old computer module; 
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Tabic 2 - Code Segments Iiriplcmcncing Stcos 4-5 and 9 

int DSLReload(uint32 moduleHandle ) 



( 



/• 4. rename DS.Nl^ to DSOLD . NLM */ 

struct LoadDef initionStructure *mh = (struct LoadDef ini tionStructure 
' ) moduleHandle ; 

char savedNaweCsizeof (mh->LDFileNaitie) ] ; 
if (!mh) 

mh s (struct LoadDef initionStruc'ture * ) registeredModule ; 
else if (moduleHandle is registeredModule) 
return ERR.I NVAL I D_ REQUEST; 



15 



20 



if (dslState != DSL.IDLE) 

return ERR.DS.LOADER_BUSY ; 
dslState = DSL_ACTIVE; 
if (mh) 
( 

/* actual rename happens here */ 

CMovB (mh*>LDFil«Naine, savedMaroe, sizeof ( savedNajne) ) ; 
CMovB (dyingKLMNanei mh->LDFileNa2ne, sizeof ( savedName) ) ; 

) 



25 



30 



/* 5. start new thread and wait for state change 
aesReload. AWalceUpOelayAinount s 0; 
aesReload. AProcessToCall = ReloadWorker ; 
aesReload. ARTag = aesTag; 

Schedules leepAESProcessEvent (fcaesReload) ; 
while (dslState == DSL_ACTIVE) 
CYieldWithO«lay() ; 



35 



40 



45 



/* 9. detect state and rename DSOLD. NLM back to DS.NLM if abort 
if (dslState »« DSL.ABORTED) 

{ 

if (mh) 
( 

CMovB ( savedKame . mh->LDFileName, sizeof ( savedName ) i ; 
/• mh->LDFlags i= oldDontUnloadBit ; */ 

) 

dslState = DSL.IDLE; 
return loadError; 

) 

if (dslState =« DSL.PROCSEDING) 
dslState = DSL_COMMITTED; 
return 0; 
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Table 3 • Code Fragments Implementing Step 6 and pan of 8 



void ReloadWorker (void) 
{ 

unsigned long oldModule . regisceredModule • 
if (d3lStace -! = DSL, ACTIVE) 
return; 

/♦ 6. call load function ♦/ 
if (loadError - LoadDSNLMO) 

/♦ 8. indicate the abort state change •/ 
if (dslstace «« DSL^ACTIVE) 

dslstate • DSL_ABORTED; 

elae if (dslState DSL^CORPSE) 

if (oldModule) 
{ 

DelayMyself (18. timerTag) ; 
KillMe (oldModule) ; 

} 

dslstate m DSL IDLE; 

} 



Table 4 . Code Fragments Implementing Step 7 and the Remainder of Step 8 



int RegiscerWithDSLoader (void) 
int err; 

uint32 dslVersion, loadedDSVersion ; 
int i; 



/* 7. negotiate versions with loader. Handle loader's rejection V 
If (err - DSLNegotiateVersions (DSVersion( ) , idslVersion 
tloadedDSVersion) ) ^asiversion, 

return err; 

if ( ! ACCEPTA3LE_DSL0ADER_VERSI0N (dslVersion) ) 

return ERR_INVALID_DS_VERSION; /* reject the loader */ • 

/* 8, commit to load new hfLM, this changes loader state •/ 
If (err . DSLRegister (DSModuleHandle ( ) , DSVersionO, tddsFuncs 
fcemuFuncs. 

DSCanUnload. DSUnload, idslMemTag, dslCommandLine) ) 
return err; 

/♦ continue ^^LM initializations ♦/ 
/* ... */ 

return 0; 
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2. Thread ^A) checks the client auihorizanon. 

3. If the client has proper authorization, usually the highest level of security clearance 
5 allowed by the system, thread (A) calls the DSLOADER and requests a reload. 

4. Thread (A) renames the memory image of the currently loaded DS.NLM to 
DSOLD.hrLM. 

10 5. Thread (A) starts thread (B) and then waits until thread (B) reports whether or not the 
load was successful. 

6. Thread (B) calls the operating system to load the new DS.NLM. This loads the new 
DS.NLM and then calls DS.NLM*s initializanon function, 

15 

7. While initializing the new DS.NLM, thread (B) reports the new DS.NLM version number 
to DSLOADER and retrieves from DSLOADER the DSOLD.NLM version number. The 
DSLOADER may reject the load with an error response or it may return the new 
DS.NLM version number. 

20 

8. Thread (B) will abort the load on an error from the loader, or if the new DS.NLM rejects 
the version number returned by DSLOADER. Thread (B) will indicate to thread (A) if it 
aborts or comnut to continue the load. 

25 9. Thread (A) detects the abort or commit state transition from thread B. If the load is 
aborted thread (A) renames the DSOLD.NLM back to DS.NLM in memory. It then 
returns from the loader. 

10. The DSOLD.NLM replies to the NCP request. 

30 

11. If Thread (B) conunits to continue the load it waits for thread (A) to complete the 
response to the NCP, then it will unload DSOLD.NLM and continue with the initialization 
of the new DS.NLM. 

35 12. Thread B terminates itself. 
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inc err = 0, managesEncry ; 
THR£ADDATA td; 

/• 1. begin servicing reload NCP •/ 

.If '-err ,= DSACii.en£Start LTD^rK£CK_OREN, ..conn -1 i ^^^^ . 

return err; ' -i.-i-tdl) 

/• 2. check client auchorizacion •/ 
i f ( IsSupervisor ( conn J 

i«anagesEntry. 0,," " "'^ ' '=^«^*i^h*<='^«*9emenc .ServerlD ( ) . ID.SELF. 
fitSt manages En try) 
else /' 3. call loader V 

err = ERK_NO_ACCESS; 

/• 10. reply to the NCP •/ 
return DSAC 1 lent End ( err) ; 
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tree to locate NDS name servers. The rendervous feature builds on another previously 
implemented capability of NetWare: SAP (Service Advertising Protocol). Routers in all installed 
NetWare intcmecworks convey SAP information for client/server rendezvous. With NDS. SAP 
has a narrowly confined role: a client uses it to find its first NDS name server. 

5 The NCP sits above the network layer. Sec Figure 3. NCP supports many nctworldng 

services, such as file services. Certain operations on an NCP connection are specific to NDS. 
Once an NCP connection exists, it can also convey NDS requests and replies. Because NDS uses 
messages that can be quite large, it employs a fragmentation protocol to convey an NDS message 
in (possibly) several NCP packets. 

10 Each NCP packet begins with a small message header that carries general sutus 

information about the current state of the connection between the client and the server. The client 
request header is seven bytes long, while a server's reply heada is eight bytes long. As shown 
below, the RequeslType variable defuies the type of network request A type of Ox 1 1 11 is 
reserved for connection allocation services; a type of 0x2222 is reserved for server request 

1 5 services; a type of 0x3333 is reserved for server responses; a type of 0x5555 is reserved for 
destroying connecnons; and a type of 0x9999 is reserved for work in progress responses. 

Reload Verb 
0x2222 104 8 



Request Format 








Offset 


Content 




Type'": 


0 


RequcstType 


(0x2222) 


WORD 


2 


SequenceNumber 


(La$tSeq+l) 


BYTE 


3 


ConnecdonHigh 


(ServiceConn) 


BYTE 


4 


TaskNumber 


(CurrentTaskNum) 


BYTE 


5 


ConnectionLow 


(SoviceConn) 


BYTE 


6 


FuncdonCode 


(104) 


BYTE 


7 


SubFuncCode 


(08) 


BYTE 
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10 



15 



20 



25 



30 



Reply Format 
Offset 

0 
2 

3 

4 

5 

(f 

7 

8 

12 



Content 

Reply Type 

SequenccNumber 

CotinectionLow 

TaskNumbcr 

ConnectionHigh 

CompletionCode 

ConnectionStatus 

NDSErrorCode 

Reserved 



Type 

(0x3333) WORD 
(LastSeq+l) BYTE 
(ServiceConn) BYTE 
(CurrcntTaskNum) BYTE 
(ServiceConn) BYTE 
(Ccode) BYTE 
(StatusFlag) BYTE 
(NDSError) 4 BYTES 

4 BYTES 



The sequence number maintains a numeric counter for all incoming requests to provide 
reply prioritization. The ConnectionLow and the ConnectionHigh numbers identify a particular 
service connection between the client and the server. The TaskNumber distinguishes which 
client process or thread is making the request to the server. 

The present embodiment of the invention uses the Reload Directory Services NCP. The 
Reload Directory Services NCP allows the principal computer program that provides directory 
seiviccs in the NetWare environment, DS.NLM. to be replaced on disk and reloaded in a server 
while that server is active and while other computer programs, NetWare Loadable Modules or 
NLMs in the NetWare environment, of the server are actively referencing NDS entry points. 

Three NLMs are involved. The DSLOADER.NLM contains the directory entry points to 
which all other NLMs actually link, including the current DS.NLM in memory and a new 
DS.NLM on disk which is to replace the current DS.NLM. 

Referring to Figure 4 and the code segments provided in Tables .... the dynamic update 
aspect of the invenuon is performed by two threads of execution within the NetWare operating 
system. The first thread (A) is the thread that begins servicing the NCP request, the other thread 
(B) is started by thread (A) to complete the reload of the new DS.NLM. The replacement 
algorithm is as follows; 

I . Thread (A) receives the RELOAD NLM NCP request in a function that is part of the 
currently loaded DS.NLM. 
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The directory provides informadon to uscn by giving users a hierarchical view of all of the 
information contained in the directory. The hierarchical view is generally in the form of a tree. 
Figure 2 shows a directory. Each of the branches and tcrminadng points or leaves represent 
objects in the directory. Generally, implementations of the directory organize objects in subtrees^ 
5 parridons or.domidns. Figure 2 also shows the dire.ctpry organized into parduons or domains. 
Multiple copies of each partition may be stored in the directory. Software schcmas define and 
determine the number and types of replicas of each partition. 

Multiple replicas of a partition are needed to reduce network storage and traffic 
requirements and speed up dircaory searches. Replicas are stored in name servers. A name 
10 server is a computer in the network, usually a network server. More than one partition can be 
stored in a nariK server. Partitions stored in a name server need not be contiguous. 

The directory tree provides a logical means of searching for information. The tree is 
generally patterned after logical groupings such as organizations, organizational units, computers 
and users. These logicd groupings, while extremely useful in helping users find relevant 
15 information also creates significant problems in managing the directory. 

Each partition forms a major subtree of the directory. Taken together, the partitions form 
a hierarchical tree of partitions that leads back to a root partition containing the root directory. 
Where boundaries of two partitions meet the partition closer to the root is considered superior, 
and the partition farther from the root is considered subordinate. Thus, Figure 2, partitions E and 
20 C arc subordinate to the other partitions. 

The prrscnt invention solves one of the problems associated with a distributed directory. 
As distributed directories become more popular, more and more users will rely on them for access 
to data and services. As user rely on directories more heavily, the time in service of the directory 
will be critical. Users will not tolerate even a temporary shut down of the directory or a portion 
25 of the directory. 
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^summary of the Invention 

Wi,h p,c»„, i„ve„u<,„ ^ compute, program, ma, provid. *e „,viccs assocu^d 
a ^s^bu.d d.«o„ can b, dy„a^c^„ , 

servcc. T™. ^ s.n,i„ o, direcor, wiU to i„cr=a„, l„«ea.i„, „^ ,„ 
directory. " 



Brief Description of the Drawings 

The present invention may be more fully understood by refenrnce to the foUowing 
Detailed Description in conjunction with the Drawings, in which: 

^Ss^t^' ' '^"^ '^"'^ ""'^^ * '^^-P"-' of its associated 

Figure 2 shows a typical directory tree; 
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25 



Detailed Description of the Invention 

The present embodiment of the invention. Novell's NetWare Direaory Service or NDS 
supports dynamically updating .he computer programs that provide distributed digital directories 
NDS operates in the NetWare network operating system environment 

TTic invention is enabled through a NetWare Core Protocol verb. NDS design builds on 
several previously implemented capabilities of NetWare, including the NetWare Core Protocol 
30 C'NCP"). -n,e first capabUity relevant to the invention is NetWare's native network layer 
protocol, IPX. IPX provides end-to-end datagram delivery over network media and over 
internetworks. 

NDS allows multiple independent name trees to coexist in the same internetwork w,u,out 
uiterfenng with each other. A rendezvous feature is defined allowing a client interested in a nan,e 



wo 96/18947 PCT/USW/15959 

Method & Apparatus To Update or 
Change A Network Directory 

5 Background 

The present invention relates to the management of distributed digital network directories, 
and particxilarly to providing dynamic updates to the computer programs supporting distributed 
directory services. 

10 Technological advances in miCTOclectronics and digital computing systems have resulted in 

the proliferation of digital computer networks, enabling the distribution of networking services 
across a wide range of computers participating in the network and over various communications 
media. Advances in distributing applications have also resulted in a client-server architecture for 
applications. Under the architecture, the portions of the application that interaa with the user arc 

1 5 typically separated from the portions of the application that fulfill client processing requcsis. 

Typically, the portions of an application thai interaa wiA the user arc called a client applications 
or client software, whereas the portions of the appUcation that service requests made by the client 
applications are called a server applications or server software. In a network environmenu the 
client applications and server applications are generally executed on different computers. 

20 Historically, digital networks in the form of local area networks, a physical collection of 

personal computers interconnected with network cabling and network interface cards, comprised 
a single network server and multiple network clients. To manage which network clients could 
access the network server, as well as what files, printers, printer queues, and server applications 
were available to the network clients, the network server nwintained information on each of the 

25 lesources that were attached to the server, the identities of the network clients and users who 

cooW use the services of the network server, and the scope and nature of the services available to 
the network clients and users. 

As local area networks became more popular, networks grew in size requiring several 
servers to service the needs of users. With inaeased size and complexity of networks, came the 
30 need for easier management of network servers. Users required access to an increasing number 
of services that were located on an increasing number of ncrwork servers. Several vendors oegan 
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